fix: parseStartAndEndTimes with times going over 12:00 by matt-franklin225 · Pull Request #330 · icssc/anteater-api

matt-franklin225 · 2026-03-05T00:11:21Z

Description

Modified the logic for calculating minutes since midnight for the start and end times of a provided time interval in packages/stdlib/src/time-utils.ts. The previous logic caused the returned time to be shifted 12 hours earlier for times that ended in hour 12, resulting in values that were 720 minutes too early (sometimes even into the negative). This issue is now fixed by more precisely comparing the start and end times and noting whether am or pm is specified.

Related Issue

This closes issue #316

Motivation and Context

This fixes a logic issue in parsing times that is relevant to the websoc and larc scrapers, removing errant responses.

How Has This Been Tested?

I tested this logic locally by testing it with a combination of input strings that worked prior and ones that gave errant results to confirm that it fixed the error without creating new ones.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

My code involves a change to the database schema.
My code requires a change to the documentation.

HwijungK · 2026-03-05T18:29:53Z

Could we rename the pr to something along the lines of "fix: parseStartAndEndTimes with times going over 12:00".

Any end time over 12:00 is now inferred to go over noon instead of midnight, not just the times that end with 12:xx.

For example, "10:00-1:00" now goes from 600 to 780 (10:00 am to 1:00 pm) instead of -120 to 60

packages/stdlib/src/time-utils.ts

laggycomputer

Times that end on hour 12 end in the hour after noon if and only if the "p" suffix is present. This means the current third example is wrong.
An example/test case with start before noon and end not before 13:00 would be good.

HwijungK · 2026-03-07T05:57:07Z

Times that end on hour 12 end in the hour after noon if and only if the "p" suffix is present. This means the current third example is wrong.

Wait i'm confused. Are we assuming that a midnight course could exist. If so it would logically make sense that '11:00-1:00' would also go through midnight.

laggycomputer · 2026-03-07T06:01:28Z

Wait i'm confused. Are we assuming that a midnight course could exist. If so it would logically make sense that '11:00-1:00' would also go through midnight.

I don't want to rule that out, because that would mean re-scraping Websoc with this fix and seeing whether it's subtly off. The format (particularly, the fact that p is used for meetings and pm is used for finals) is very consistent.

matt-franklin225 · 2026-03-09T19:37:21Z

I don't want to rule that out, because that would mean re-scraping Websoc with this fix and seeing whether it's subtly off. The format (particularly, the fact that p is used for meetings and pm is used for finals) is very consistent.

In that case, is the passing midnight situation something we should account for, and if so, how do we handle minutes after midnight? We could either return them as minutes since the most recent midnight or minutes since the starting midnight.

HwijungK · 2026-03-09T19:43:43Z

is the passing midnight situation something we should account for, and if so, how do we handle minutes after midnight

My best guess is that if there every is a case like that, the date would reference the earlier day, so Mar 9, 11:00-1:00 would probably mean at 11:00 on Mar 9 and ending 1:00 on Mar 10. It would probably be more right to say that the ending time is after 24*60, then to have a negative start time

matt-franklin225 · 2026-03-09T19:51:38Z

My best guess is that if there every is a case like that, the date would reference the earlier day, so Mar 9, 11:00-1:00 would probably mean at 11:00 on Mar 9 and ending 1:00 on Mar 10. It would probably be more right to say that the ending time is after 24*60, then to have a negative start time

Lmk what you think of the new version

HwijungK

this is breaking for "normal" pm time intervals like 3:00-4:00p, where the end time returns an hour greater than 24 * 60, and creates 12+ hr intervals for times going over midnight b/c the starttime isn't being pushed along with the end time

matt-franklin225 · 2026-03-11T21:23:15Z

this is breaking for "normal" pm time intervals like 3:00-4:00p, where the end time returns an hour greater than 24 * 60, and creates 12+ hr intervals for times going over midnight b/c the starttime isn't being pushed along with the end time

Previous issue should be fixed now

HwijungK

Looks good to me 👍👍

laggycomputer · 2026-03-13T02:18:54Z

packages/stdlib/src/time-utils.ts

+  if (endTimeMinute.includes("p") && startTime <= endTime) startTime += 12 * 60;
+  if (endTimeMinute.includes("p") && startTime > endTime) endTime += 12 * 60;


can we make these the same if and add a really short comment showing what sort of case we're trying to account for in both cases?

Restructured the if statements and added a couple comments

laggycomputer

Sorry, I meant to lean more toward examples on (currently) lines 26 and 30.
Line 30 as is is somewhat clear, but the comment on line 26 doesn't add much.

initial fix for parsing times

6449626

matt-franklin225 temporarily deployed to staging-330 March 5, 2026 00:11 — with GitHub Actions Inactive

matt-franklin225 marked this pull request as ready for review March 5, 2026 00:17

matt-franklin225 requested a review from laggycomputer March 5, 2026 00:18

HwijungK reviewed Mar 5, 2026

View reviewed changes

packages/stdlib/src/time-utils.ts Outdated Show resolved Hide resolved

matt-franklin225 changed the title ~~fix: parseStartAndEndTimes with times ending in hour 12~~ fix: parseStartAndEndTimes with times going over 12:00 Mar 5, 2026

detailed examples added for time-utils.ts

bdd92cb

laggycomputer requested a review from HwijungK March 5, 2026 22:46

matt-franklin225 temporarily deployed to staging-330 March 5, 2026 22:54 — with GitHub Actions Inactive

laggycomputer linked an issue Mar 6, 2026 that may be closed by this pull request

parseStartAndEndTimes can't handle times ending in hour 12 #316

Open

laggycomputer requested changes Mar 7, 2026

View reviewed changes

adjusted handling midnight passing for time-utils

06231a6

matt-franklin225 temporarily deployed to staging-330 March 9, 2026 19:51 — with GitHub Actions Inactive

HwijungK reviewed Mar 9, 2026

View reviewed changes

fixed breaking in time-utils

cc1279d

matt-franklin225 temporarily deployed to staging-330 March 10, 2026 19:19 — with GitHub Actions Inactive

laggycomputer requested a review from HwijungK March 11, 2026 22:06

HwijungK approved these changes Mar 11, 2026

View reviewed changes

matt-franklin225 requested a review from laggycomputer March 13, 2026 02:16

laggycomputer requested changes Mar 13, 2026

View reviewed changes

comments/adjustments added to time-utils

958941a

matt-franklin225 deployed to staging-330 March 13, 2026 07:42 — with GitHub Actions View deployment

matt-franklin225 requested a review from laggycomputer March 13, 2026 08:09

laggycomputer requested changes Mar 13, 2026

View reviewed changes

		if (endTimeMinute.includes("p") && startTime <= endTime) startTime += 12 * 60;
		if (endTimeMinute.includes("p") && startTime > endTime) endTime += 12 * 60;

Conversation

matt-franklin225 commented Mar 5, 2026

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Uh oh!

HwijungK commented Mar 5, 2026

Uh oh!

Uh oh!

laggycomputer left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HwijungK commented Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laggycomputer commented Mar 7, 2026

Uh oh!

matt-franklin225 commented Mar 9, 2026

Uh oh!

HwijungK commented Mar 9, 2026

Uh oh!

matt-franklin225 commented Mar 9, 2026

Uh oh!

HwijungK left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matt-franklin225 commented Mar 11, 2026

Uh oh!

HwijungK left a comment

Choose a reason for hiding this comment

Uh oh!

laggycomputer Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

matt-franklin225 Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

laggycomputer left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

laggycomputer left a comment •

edited

Loading

HwijungK commented Mar 7, 2026 •

edited

Loading

HwijungK left a comment •

edited

Loading

laggycomputer left a comment •

edited

Loading